For many products and/or services a customer or subscriber desires that a financial charge for the product/service be satisfied or paid from one or more of accounts, e.g., asset accounts owned by the customer or authorized for the customer's use. The debiting of the appropriate accounts, or reserving of assets in the appropriate accounts, is generally handled by a charging system. An example of an online charging system (OCS) is described in U.S. patent application Ser. No. 12/258,990 of ABRAHAMSSON et al, entitled REAL-TIME FLEXIBLE ACCOUNT SELECTION FOR COMMUNICATIONS, which is incorporated herein by reference.
An online charging system (OCS) generally performs charging authorization for use of a service or a set of services. When a subscriber starts to use a service, the OCS either authorizes or denies the subscriber relative to the service sought. If the subscriber is allowed to use the service, the OCS authorizes an amount or quota that the subscriber can use for the service before seeking new authorization. The OCS can also set a time limit for how long the subscriber can use the authorized quota before seeking new service authorization. The quota is typically data volume and/or time, but can also be defined by the service provider (for example charging for electricity using kw/hour as quota unit).
In real-time session-based charging, common data that is shared by different sessions/activities can be modified by these sessions/activities. When a session/activity has initiated an action, subsequent sessions/activities may initiate the same action again. If the action requires reserving the users' (subscribers') resources, then the users' resources will be reserved for each action initiated by a session/activity.
In order to commit the initiated action, the session/activity must fulfill certain update conditions. An action initiated by a session must be committed by the same session.
One problem with the existing solution of common data modification is that the shared data can be modified by the same action initiated repeatedly by parallel sessions/activities. The sessions can be initiated by the same user or by different users sharing common data. The repeated actions will cause an undesired effect. If the action requires reserving the users' resources, then the unwanted repeated actions will tie up the users' resources. Another problem is that the initiated action has to be committed by the session that initiated it. Even if another session has fulfilled the commit conditions earlier, it cannot commit the action initiated by that session. This causes a delay in the commit action and plausibly ties up the users' resources even longer.